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ABSTRACT 
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This paper outlines the work done to date and assesses the applicability of this modified ASN.l 
is illustrated with several examples. 


as a DDL. The feasibility of the approach 
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The Problems of Interchanging Data 

The Droblems of data interchange are primarily those associated with providing the destination (potentially a 
feient computer environment) with all the information it needs to be able to interpret the received data ^At 
present, a typical data interchange system is dedicated to a particular flight mission or project. Data is acquired 
processed, shared to some level with other members of the investigating team and eventually archived Further’ 
documentation of the data and its format may not be complete and up-to-date. This practice results in the need 

period diffmult! 11610 * 131186 ^ SySt6m ^ ^ m ' SSi ° n a " d makes the reuse of data and software at some future 


Overview of the CCSDS Approach 


The CCSDS approach is to provide standardised techniques for the automated interpreting of data products in a 
eterogeneous computer environment. It puts no constraint on the format of the user data and can thus 
accommodate formats developed by other organisations or user communities. It offers a data labelling scheme 
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which permits associating a data instance and its (in principle separate) complete and unambiguous description. 
Further, it allows the development of generic software to support the retrieval, access, parsing and presentation 
of data to satisfy particular application and user needs. Three major stages are identified in the data interchange 
process and are explained in this paper. 


The Data Interchange Requirements 

To achieve the stated aims, the fundamental requirement that has to be fulfilled is the unambiguous description 
of data that has to be interchanged between users separated by both time and space. When received, data have 
to be understood fully. This means that the receiver has to not only be able to read the data from the transfer 
media and understand the basic physical elements of the data (e.g. an integer), but also the receiver must be able 
to understand the real world meaning of the data. For example, there is no point in the receiver knowing that the 
10 th and 1 1 1 * 1 bytes of the received data are an integer of value 145, if he also does not know that this conveys 
the temperature of a spacecraft instrument in degrees Kelvin. 

Further, it is desirable that data products be automatically transferable without requiring any conversion of their 
contents. It is also desirable that transfers would be possible regardless of the source or destination computer 
types. In other words, 

• the data must remain in its original form, i.e. does not need to be converted in order to be interpreted at 
the destination; 

• the destination needs to know nothing about the source, regardless of how different the computer systems 
may be. 

Thus, the approach presented in this paper is to use a data description processable on any computer which will 
allow the transmission of data in its native form, i.e. no data encoding will be required. 


The Three Stages of the Data Interchange Model 

In an attempt to establish a logical model of the whole data description process, an initial assumption was made, 
that is that the description of data can be cleanly split between the physical description (called the syntax 
description) and the meaning of those physical elements (called the semantic description). In fact, as the problem 
domain was studied further, it was realised that the description should be split into 3 parts, the same physical 
description as originally perceived, but the meaning component was really 2 separate components: the meaning 
of the physical elements being exchanged and furthermore the methods of combining the physical elements or 
relationships between these elements. Indeed, a generator of data products not only wishes to convey the physical 
data and its meaning, but also how they are intended to be interpreted taking into account their context. Figure 
1 shows the model defined by the CCSDS to represent the following stages of data description: 

Stage 1: Data is initially perceived as a group of bits accessible from a physical medium and is read in 
combination with its syntax description. This tells the user the physical layout of the data on the medium, which 
bits are grouped with each other and how they should be read by common computer hardware (e.g. as integers, 
reals, bit masks, etc). The syntax description must include all the physical bits, all the bits and groupings must 
be named in some way. At this stage it is possible to manipulate the basic values, for example converting to 
another physical representation, e.g. from VAX reals to IBM reals. 


Stage 2: The next stage is when the physical data is read in conjunction with its basic semantic description: this 
only describes those parts of the data that the user is interested in fully understanding, i.e. the basic semantic 
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Figure 1: Data Interchange Logical Model 

description could be perceived as a filter that covers the physical layout of the data and only allows those elements 

factor ? rr wT ^ ‘ hlS S u ge ’ ^ relevant inform ation is typically: meaning, units, aliases, scaling 
. The elements which are not called out in the basic semantic description are still physically present but 

not of interest to the user. Different users may use different semantic descriptions which will act as different 
masks over the same physical data and therefore perceive the data product in a different manner. Interfacing to 
the data at this level is the most common method within present day data processing systems. 8 

S tage 3: The final stage in the understanding of the data is to add advanced semantics: these do not define the 

snecT™!™ 1118 °/ Ti' P ‘ eCe ° f data ’ bl “ the Way different P ieces of data are related to each other. This may be 
specified m a natural language or as a mathematical algorithm or as a process defined in a programmable computer 

guage. The elements thus created are called conceptual elements, as they never actually physically exist- P they 
are pieces of information that are carried within an application domain. If they were ever written as a piece of 
physical data to a physical media, then this whole process would start from the beginning, i.e. with applying their 
syntax description Figure 1 shows a • at the point where the advanced semantics are applied, th.sTs to indicate 
that some form of processing takes place. For example, the data may contain two integers, named mass and 
volume and for these named physical elements the advanced semantic description may also tave a defmWon of 
density , as being a relationship between the two physical elements mass and volume. 


Applicability of MADEL as a DDL 


As the model shows, a mechanism must exist at each stage in order to link the data perceived so far to the syntax 
ot semantic information being added. This paper focuses on stage 1: MADEL has been developed to perform 
yntactic description of the physical data. Regarding stage 2, it is noted that CCSDS has developed a DDL 
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called PVL (Parameter Value Language) suited to handle the basic semantic description (see Reference-2). 
Regarding stage 3, processing is in practice very much application specific. Stages 2 and 3 are not covered further 
in this paper. 

The reasons for selecting ASN.l (see Reference- 1) as a starting point of the MADEL development are that ASN.l 
is an International Standard, is familiar to the CCSDS community and intuitive to understand, even by the non 
expert users. It must be noted at this point that ASN.l is used as a separate DDL for describing data formats and 
not as it was originally designed that is, embedding within the data to be transferred auxiliary information ("ASN.l 
encoding"). Hence, in the process of deriving MADEL, limitations were made as were some extensions added 
in order to fulfil the requirements as stated earlier. The most significant modifications to the ISO 8824 ASN.l 
specification are detailed below: 


Physical Representation of Base Types 

Typical MADEL description statements are Spacecraf tlD j : = OCTET string or Width : s = real. 
Since the intention is to keep the physical data in its native form and to have the MADEL description in 
accordance with Reference- 1, defaults must be adopted everywhere a complete description of the data is not 
supplied directly by the MADEL description itself. For example how many octets are in Spacecraf tlD and 
how many bits are used for the mantissa of width and where are these bits located within the real number layout? 
These pieces of information must be provided in some manner, down to the bit level where necessary and are 
catered for by MADEL. 

For example, real numbers are described using the MADEL REAL type whose defaults describe ANSI/IEEE 754 
floating point numbers or using a generalised form of the REAL type: this type, to be used for any non 

ANSI/IEEE 754 real numbers, provides the capability to fully describe a real number physical layout in terms of 
mantissa, exponent, base, etc; thereby allowing to compute at the destination the real number value from: 

ValueOfRealNumber = -l Sign x Mantissa x Base ^nnt-Bias 


Real Time Data Selection 


The purpose of this modification to ASN.l is to allow the description of situations where one possibility has to 
be selected among several alternatives at the time the physical data is being received. Such situations are typical 
in space related applications: for example the value of the first byte in the physical data could indicate the format 
of satellite tracking measurement samples - Doppler/Ranging/Meteo --) or a layout word at the beginning of a 
housekeeping telemetry frame would indicate whether commands acknowledgement or memory dumps 
or attitude parameters are contained in that particular frame received on ground. -Thus, the format of a 
piece of data typically is dependent upon a value of another piece of data (called the discriminant) and it should 
be possible to describe this aspect. 


It has been felt that this ability is fundamental to existing space related data products and since at present ASN.l 
does not have it, MADEL has been designed to support it: to this end, the select type has been introduced. 
Thus with MADEL, the discriminant conveyed within the physical data can be processed in order to dictate the 
branch to be selected, without needing any encoding/decoding mechanism. Furthermore, the type of the 
discriminant itself must also be specified, for example, integer, real, IA5 String. The format of the 
select statement in a MADEL description would be: 


Packet ::= SELECT PacketType { 


"AX" 

"HK" 


-- PacketType is the discriminant 
Auxiliary Packet , 

HouseKeepingPacket , 
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'NS" : NormalSciencePacket, 
"BS" : BurstSciencePacket 

} 


together with the following discriminant definition: 


PacketType = IA5String( SIZE (2)) 


Implementation of the MADEL Interpreter 


The task of interpreting a MADEL description together with an instance of the corresponding physical data is 
achieved (and demonstrated) by prototype software called the MADEL Interpreter. An overvietofthe MADEL 

strucfures" ‘ eCtUrc ‘ S Sh ° Wn ln FlguIe 2: this shows the main Processes that are involved and the critical data 



Running the MADEL Interpreter 

^ fe6dS int ° the MADEL 'nteipreter a MADEL description of his data and the physical data file The 
MADEL description is verified for correctness by the MADEL Description Verifier module. 

• The verified MADEL description is then parsed by the Syntax Tree Generator and a syntax tree of the data 
structure defined in the MADEL description is built internally. This internal tree represents the full c 
escnption that is defined including all possible choices or selections. Figure 3 shows a schematic of such alree 
for a simple data structure: Element A is defined as a sequence of element B (an integer) followed hv r r! 
octet) followed by D (a selection) which is dependent upon the value at reception tinfe of the integerB (the 

be nTa S' Finally d £” be Q (a se <l uence ) and if B = 3 D till 

. Th/v i t r- y f Q ls u selected then thls Wl11 be a sequence of X (an integer) followed by Y (a real) 

the s V <* ^ Tree Generator then walks down *e syntax tree reading the corresponding physical data driven by 
the syntax tree. It sees at the top of the syntax tree that the first element is a sequence, this corresponds to no 
ac ual physical data, so it creates the top node of the value tree with no data, just a flag indicating a sequence 
then goes on to read the elements of the sequence; firstly an integer, so bits are read from the physical data 
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and the Value Tree Generator adds a node to the value 
tree which it fills with the local representation of the 
actual value. Following this, the octet corresponding to 
C is read in the same manner. Again the select element 
D corresponds to no physical data, but the selection is 
dependent upon the value of B, so the value of B already 
stored in the value tree is accessed and the relevant 
branch of the syntax tree taken. Say B was 2, then 
branch Q is selected, so this branch of the syntax tree is 
followed and the corresponding branch of the value tree 
created. The resultant value tree is shown schematically 
in Figure 4. Eventually this tree will store the local 
representation of all selected physical data, and the user's 
application can proceed with stage 2 of the model (see 
Figure 1) or access the data using conventional methods. 
This link to the local representation of the values 

received in the physical data fulfils the task defined in 
stage 1 of the model. 


Implementation and Support Tools 


The MADEL Interpreter was developed on an IBM PC 
running MS-DOS, with Borland-C++ and MKS Lex & 

Yacc as major development tools. It is written in the C 
language. 

Test data sets, along with ‘their corresponding MADEL 
descriptions must be generated for test purposes. To this 
end support tools have been developed. A MADEL 
description is created with a normal text editor and fed 
into the MADEL Interpreter in ASCII text form. The 
physical data can be created interactively and a user interface mechanism has been integrated so that the user be 
provided with facilities to (i) select a MADEL description, then (ii) be guided in the production of associated 
physical test data. 



Figure 4: Schematic of the Value Tree Generated 
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Figure 3: Schematic of the Syntax Tree Generated 


Conclusions 

• The study has shown the feasibility of the CCSDS concept and the analysis performed while developing MADEL 
has shown that, if some simple defaults and extensions are adopted (as have been defined), ASN.l can be used 
satisfactorily as the basis for a suitable DDL. In particular it can fulfil the fundamental need for real time selection 
of data in the description of space related data. It should be noted that an important facet of the work was that 
MADEL, in terms of its syntax, has been kept very close to ASN.l (as defined in the ISO 8824 standard). 

• Prototype software (the MADEL Interpreter) was developed which demonstrated that typical space related data 
formats can be interchanged between heterogeneous computer environments and interpreted. In turn, this "proof 
of concept" development and testing helped to improve the overall data interchange model and to identify possible 
future additions to MADEL. User interface aspects were also studied. 
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• The MADEL Interpreter could become the basis of a set of tools for supporting data interchanges Data nrodnrt 
definitions or interface definitions written in MADEL could be generated and given to all users^hus avoiding the 

need for paper Interface Control Documents or paper format definitions. This would ensure that all users have 
a unique, correctly coded product description. 

' , the , l 0 n f ei term - sta ge 3 ° f ^e data interchange model should be looked at with the objective of defining 
standardised approaches and identifying common software services for the processing of advanced semantics . 8 


EXAMPLES 


E x ample 1; Interchanging Real Niimher s LfoQm VAX to ipm 


Hexadecimal dumps of VAX real numbers were generated on a vax/vmq 

The corresponding MADEL description was created (this fileT^nd^w P t6r * ^ 

by the MADEL interpreter on an P lBM PC to Cte^prit^he'corLspond^g ^daff 

GFloatNumber structure on VAX 

Word_l {Sign:l , Exp: 11 , Mant:4} 

Word—2 Word_3 Word_4 : all [Mant: 16} 


Word 1 

{Sign : 1 , 

Exp: 8 , Mant: 7} 






Word_2 

{Mant: 16} 






- - Case 1 








-- GFloatDump 
-- FFloatDump 

Value = 
Value = 

-2.0000 Phys . 

-2.0000 Phys. 

Hex. 
Hex . 

= C020 
= C100 

0000 

0000 

0000 

0000 

-- Case 2 








-- GFloatDump 
■“ FFloatDump 

Value = - 
Value = - 

64071.5000 Phys. 

64071.5000 Phys. 

Hex . 
Hex. 

= C10F 
= C87A 

48F0 

4780 

0000 

0000 


MADEL Definition starts here: 


VaxVmsReals DEFINITIONS 
BEGIN 


List-of -VaxNumbers ::= SEQUENCE SIZE{ 2 ) OF Numbers 
Numbers : : = SEQUENCE { 

GFloatNumber, 

FFloatNumber 

} 


2 cases in this example 


GFloatNumber : := REAL { 

BIAS (1025), 
COMPLEMENT ( 0 ) , 
BASE ( 2 ) , 

MANTISSA_MODE ( 1 ) , 
MANTISSA ( 12 , 63 ) , 
EXPONENT ( 1,11) 


-- bias value 

-- 0, 1 or 2 1 s complement indicator 
““ base value 

algorithm for mantissa evaluation 
-- mantissa bit positions 
exponent bit positions 


FFloatNumber 


REAL { 

BIAS( 129) 

} 


using ANSI/IEEE 754 defaults for REAL type 
except bias which is VAX specific 


END 


MADEL Interpreter Execution Report: 


Symbol Name . . . : GFloatNumber 

S; '- Ze 64 Type Name . . . : REAL 

Exponent_bits = (1..11), Mantissa_bits = (12.. 63), 
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Complement = 0, Base = 2, Bias = 1025, Mantissa_Mode = 1 
PHYSICAL REPRESENTATION . : 11000000 00100000 00000000 00000000 

00000000 00000000 00000000 00000000 

HOST REAL NUMBER = -2 


Symbol Name . . . : FFloatNumber 

Size : 32 Type Name . . . : REAL 

Exponent_bits = (1..8), Mantissa_bits = (9.. 31), 

Complement = 0, Base = 2, Bias = 129, Mantissa_Mode = 1 
PHYSICAL REPRESENTATION . : 11000001 00000000 00000000 00000000 
HOST REAL NUMBER = -2 


Symbol Name . . . ; GFloatNumber 

Size : 64 Type Name . . . : REAL 

Exponent„bits = (1..11), Mantissa_bits = (12.. 63), 


Complement = 0, Base = 2, Bias = 1025, Mantissa_Mode = 1 
PHYSICAL REPRESENTATION .: 11000001 00001111 01001000 11110000 

00000000 00000000 00000000 00000000 
HOST REAL NUMBER = -64071.5 


Symbol Name . . . : FFloatNumber 

Size : 32 Type Name . . . : REAL 

Exponent_bits = (1..8), Mantissa_bits = (9.. 31), 

Complement = 0, Base = 2, Bias = 129, Mantissa_Mode = 1 


PHYSICAL REPRESENTATION . : 11001000 01111010 01000111 10000000 
HOST REAL NUMBER = -64071.5 


Example 2; Real Time Data Selection 


-- This example is a special case of the data format discussed in Figure 3 
-- and illustrates further the dynamics of data interpretation at the destination 

-- MADEL Definition starts here: 

Example-of -DataRealTimeSelection DEFINITIONS ::= 

BEGIN 



P 
Q 
R 
X 
Y 
END 


SEQUENCE 

{ B, 

C, D } 

INTEGER 


-- specification of the discriminant 

OCTET STRING 


SELECT B 

{ 

-- B is discriminant for selecting 


1 

P, 


2 

Q, 


3 

} 

R 

INTEGER 

SEQUENCE 

REAL 

{ x 

Y } 

INTEGER 


description of the lowest level elements in 

REAL 


the data format A 


MADEL Interpreter Execution Report: 


Symbol Name . . . : B 

Size : 16 Type Name . . . : INTEGER 

PHYSICAL REPRESENTATION . : 00000000 00000010 
INTEGER VALUE = 2 


Symbol Name . . . : C 

Size : 1 Type Name . . . : OCTET 

PHYSICAL REPRESENTATION . : 00101010 
OCTET STRING VALUE = ' * ' 


Symbol Name . . . : D 

Size : 16 Type Name . . . : SELECT 
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PHYSICAL REPRESENTATION . : 
SELECTED BRANCH = 2 


see symbol B 


Symbol Name . . . : x 

Size 16 

PHYSICAL REPRESENTATION 
INTEGER VALUE = 129 


Type Name . . . : INTEGER 

. : 00000000 10000001 


Symbol Name . . . : y 

Size 32 

Exponent_bits = (1..8), 
Complement = 0, Base 
PHYSICAL REPRESENTATION 
HOST REAL NUMBER =1.5 


Type Name . . . ; real 
M antissa_bits = (9.. 31), 

2, Bias = 128, Mantissa_Mode = l 

. : 01000000 01000000 00000000 00000000 
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